## **Description**

This PR is from an external contributor. Initial review and context
[here](#23270)

Credit @Nodonisko 

This PR implements new `@metamask/native-utils` package for C++
cryptography instead of JS implementation. That provides significant
performance improvements all across the app. Most visible improvements
are during app startup and SRP imports, but for example `keccak256`
helps also in many other places.

This PR should also have really nice synergy with
MetaMask/core#6654 that could shave of another
tens of percent for login times.

For now I am patching `@metamask/key-tree`, once
MetaMask/key-tree#223 is done, patch could be
removed, but it may take a while.

### Performance Optimization Results

Device: Pixel 4a 5G
Tested on SRP with 200+ accounts.

| Metric | Before Optimization* | After Optimization | Improvement | %
Faster |
| :--- | :--- | :--- | :--- | :--- |
| **App Loaded to Login screen** | 7s 333ms | **4s 750ms** | ⚡️ 2.58s
faster | **35.2%** |
| **Dashboard Loaded** | 14s 0ms | **6s 333ms** | ⚡️ 7.67s faster |
**54.8%** |
| **App is Responsive (60 FPS)** | 18s 783ms | **12s 166ms** | ⚡️ 6.62s
faster | **35.2%** |
| **SRP Import (Discovery)** | 276s 616ms | **203s 450ms** | ⚡️ 73.17s
faster | **26.5%** |

_* Before optimalization version has `@metamask/native-utils` completely
removed (including secp256k1 that was merged before)._

There should be around 200 - 300ms improvement in account creation time
but I am not including this in result because I did many measurements
but spread was too big to conclude any results from it. Another big
improvement for acccount creation should be
MetaMask/core#6654

## **Changelog**

<!--
If this PR is not End-User-Facing and should not show up in the
CHANGELOG, you can choose to either:
1. Write `CHANGELOG entry: null`
2. Label with `no-changelog`

If this PR is End-User-Facing, please write a short User-Facing
description in the past tense like:
`CHANGELOG entry: Added a new tab for users to see their NFTs`
`CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker`

(This helps the Release Engineer do their job more quickly and
accurately)
-->

CHANGELOG entry: null

## **Related issues**

Fixes:

## **Manual testing steps**

1. All accounts are discovered
2. Balances for tokens and total balance is correct
3. Correct receive addresses are generated

## **Screenshots/Recordings**
 
### Startup + Login



https://github.com/user-attachments/assets/24c8ca90-5475-4fa8-9062-30f6fa5133b2

### SRP Import

Observe also FPS counter, as you can see optimized version is
maintaining higher FPS (around ~20) compared to non-optimized (around
~10). That should be enough to make app usable even on very slow device
during running accounts discovery. To improve FPS even more we need to
optimize rerenders and some selectors.

In order to reduce discovery total time even more it would require
different strategies of discovery, for example instead doing account
detail requests one by one, until you find empty one, you could for
example request them in batches of 3 which should improve total time
significantly.



https://github.com/user-attachments/assets/9f6c9825-5d97-415e-903c-8f4327273a2d

## **Pre-merge author checklist**

- [ ] I’ve followed [MetaMask Contributor
Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile
Coding

Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md).
- [ ] I've completed the PR template to the best of my ability
- [ ] I’ve included tests if applicable
- [ ] I’ve documented my code using [JSDoc](https://jsdoc.app/) format
if applicable
- [ ] I’ve applied the right labels on the PR (see [labeling
guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)).
Not required for external contributors.

## **Pre-merge reviewer checklist**

- [ ] I've manually tested the PR (e.g. pull and build branch, run the
app, test code being changed).
- [ ] I confirm that this PR addresses all acceptance criteria described
in the ticket it closes and includes the necessary testing evidence such
as recordings and or screenshots.



<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> Replaces JS crypto with native implementations via
@metamask/native-utils, adds perf shims, patches key libs, and updates
tests/config to support it.
> 
> - **Crypto performance**:
> - Add `shimPerf` to monkey-patch `@noble` and `js-sha3`
(`secp256k1.getPublicKey`, `hmacSha512`, `keccak256`) to use native C++
via `@metamask/native-utils`.
>   - Update `shim.js` to load `shimPerf`.
> - Switch `quick-crypto` string encoding to `TextEncoder` for key
derivation/encryption.
> - **Library patches**:
> - Patch `@ethereumjs/util` to export `pubToAddress` from
`@metamask/native-utils`.
> - Patch `@metamask/key-tree` `ed25519` to use
`native-utils.getPublicKeyEd25519`.
> - **Selectors**:
> - Optimize `selectInternalAccounts` sorting to pre-compute indices and
reduce `toFormattedAddress` calls.
> - **Testing/config**:
> - Add Jest mock `app/__mocks__/@metamask/native-utils.js` and map in
`jest.config.js`; extend `transformIgnorePatterns`.
> - **Dependencies/Pods/Lockfiles**:
> - Bump `@metamask/native-utils` to `^0.8.0` (iOS `NativeUtils` pod
0.8.0).
> - Add `js-sha3@0.9.3`, pin `@noble/hashes@1.8.0`, add Yarn
patches/locks for `@ethereumjs/util@9.1.0` and
`@metamask/key-tree@10.1.1`.
> 
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
95728ed. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->



<!--
Please submit this PR as a draft initially.
Do not mark it as "Ready for review" until the template has been
completely filled out, and PR status checks have passed at least once.
-->

## **Description**

<!--
Write a short description of the changes included in this pull request,
also include relevant motivation and context. Have in mind the following
questions:
1. What is the reason for the change?
2. What is the improvement/solution?
-->

## **Changelog**

<!--
If this PR is not End-User-Facing and should not show up in the
CHANGELOG, you can choose to either:
1. Write `CHANGELOG entry: null`
2. Label with `no-changelog`

If this PR is End-User-Facing, please write a short User-Facing
description in the past tense like:
`CHANGELOG entry: Added a new tab for users to see their NFTs`
`CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker`

(This helps the Release Engineer do their job more quickly and
accurately)
-->

CHANGELOG entry:

## **Related issues**

Fixes:

## **Manual testing steps**

```gherkin
Feature: my feature name

  Scenario: user [verb for user action]
    Given [describe expected initial app state]

    When user [verb for user action]
    Then [describe expected outcome]
```

## **Screenshots/Recordings**

<!-- If applicable, add screenshots and/or recordings to visualize the
before and after of your change. -->

### **Before**

<!-- [screenshots/recordings] -->

### **After**

<!-- [screenshots/recordings] -->

## **Pre-merge author checklist**

- [ ] I’ve followed [MetaMask Contributor
Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile
Coding
Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md).
- [ ] I've completed the PR template to the best of my ability
- [ ] I’ve included tests if applicable
- [ ] I’ve documented my code using [JSDoc](https://jsdoc.app/) format
if applicable
- [ ] I’ve applied the right labels on the PR (see [labeling
guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)).
Not required for external contributors.

## **Pre-merge reviewer checklist**

- [ ] I've manually tested the PR (e.g. pull and build branch, run the
app, test code being changed).
- [ ] I confirm that this PR addresses all acceptance criteria described
in the ticket it closes and includes the necessary testing evidence such
as recordings and or screenshots.

---------

Co-authored-by: Daniel Suchý <suchydan@gmail.com>

… send flow (#21498)

## **Description**

### Problem:
Fixed four critical issues with QR scanner in the redesigned send flow:

1. Navigation failure - QR scanner wasn't navigating to send flow after
scanning addresses. The camera modal would close but no navigation
occurred.
2. Missing recipient pre-population - Scanned addresses weren't
appearing in the recipient input field in the redesigned send flow.
3. Limited blockchain support - Only supported Ethereum addresses.
Solana, Bitcoin, and Tron addresses were not recognized or handled.
4. Camera resource leak - Camera continued scanning after navigation,
causing continuous barcode processing, log spam, wasted CPU/battery, and
potential privacy concerns

### Solution:
Navigation & Recipient Pre-population:
- Implemented proper navigation timing by closing the QR scanner modal
first, then using `InteractionManager.runAfterInteractions()` to
navigate to send flow
- Added `predefinedRecipient` parameter with address and chain type to
`navigateToSendPage()` to pre-populate recipient field
- Added `QRScanner` to `InitSendLocation` constants for proper metrics
tracking
- Updated send flow logic to start at asset selection screen when
recipient is pre-populated from QR scan

Multi-chain Support:
- Added support for Solana addresses using `@solana/addresses
`validation
- Added support for Bitcoin addresses using `isBtcMainnetAddress()`
- Added support for Tron addresses using `isTronAddress()` 
  - Tron is currently disabled and will show an alert for now
- Each blockchain type is properly identified and passed with correct
chainType (ChainType.SOLANA,
ChainType.BITCOIN, ChainType.TRON, ChainType.EVM)

## **Changelog**

CHANGELOG entry: Fixed QR scanner navigation by chain type and recipient
address pre-population in send flow

## **Related issues**

Fixes: https://consensyssoftware.atlassian.net/browse/TMCU-75
#17283

## **Manual testing steps**

```gherkin
  Feature: QR Scanner recipient pre-population

    Scenario: user scans QR code with EVM address
      Given user is on wallet home screen
      When user taps QR scanner icon
      And user scans QR code containing "0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb"
      Then app navigates to send flow asset selection screen
      And recipient address field is pre-populated with scanned address
```

## **Screenshots/Recordings**

Sending EVM


https://github.com/user-attachments/assets/a7999672-4a06-4e38-abdb-2608d9605bb5


Send SOL


https://github.com/user-attachments/assets/43cb23a8-130d-47fa-94d5-ac8d7693a13f

Send BTC


https://github.com/user-attachments/assets/b15b5df5-2bab-4292-9d84-9a58544bdc6c

Tron Alert


https://github.com/user-attachments/assets/dd416270-2c97-4e31-9444-021aaf30878e

### **Before**


https://github.com/user-attachments/assets/5950a84f-45cc-480b-b6ea-9dadb28db91c


### **After**


https://github.com/user-attachments/assets/a7999672-4a06-4e38-abdb-2608d9605bb5

## **Pre-merge author checklist**

- [x] I’ve followed [MetaMask Contributor
Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile
Coding
Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md).
- [x] I've completed the PR template to the best of my ability
- [x] I’ve included tests if applicable
- [x] I’ve documented my code using [JSDoc](https://jsdoc.app/) format
if applicable
- [x] I’ve applied the right labels on the PR (see [labeling
guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)).
Not required for external contributors.

## **Pre-merge reviewer checklist**

- [x] I've manually tested the PR (e.g. pull and build branch, run the
app, test code being changed).
- [x] I confirm that this PR addresses all acceptance criteria described
in the ticket it closes and includes the necessary testing evidence such
as recordings and or screenshots.








<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> QR scanner now closes camera and navigates to the redesigned send flow
with a prefilled recipient across EVM, Solana, and Bitcoin (Tron
temporarily blocked), with improved metrics, validation, and tests.
> 
> - **QR Scanner behavior**:
> - Closes scanner and, via `InteractionManager`, navigates to send flow
using `useSendNavigation` with `predefinedRecipient` and
`InitSendLocation.QRScanner`.
> - Manages camera lifecycle with `useFocusEffect` and `isCameraActive`
to prevent repeated scans.
> - **Multi-chain address support**:
> - Adds handling/validation for `Solana` (`@solana/addresses`) and
`Bitcoin` (`isBtcMainnetAddress`); routes to send flow with correct
`chainType`.
> - Detects `Tron` (`isTronAddress`) but blocks with alert and metrics;
treats as `address_type_not_supported`.
> - Extends QR address validation (`isValidAddressInputViaQRCode`) to
Solana/Bitcoin/Tron.
> - **Metrics & constants**:
> - Tracks outcomes with new `ScanResult.ADDRESS_TYPE_NOT_SUPPORTED` and
refined QR scan events.
> - **Send flow**:
> - Updates navigation tests to start at `Asset`/`Amount`/`Recipient`
screens based on `predefinedRecipient` and asset.
> - **i18n**:
>   - Adds `qr_scanner.tron_address_not_supported` copy.
> - **Tests**:
> - Extensive unit tests for EVM, Solana, Bitcoin, Tron paths, URL
confirmations, and camera/permission states.
> 
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
dd53ceb. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

…23752)

## **Description**

Follow-up to #23747 (HIP-3 connection optimization). This PR further
optimizes Perps initialization by using WebSocket transport for
InfoClient API calls instead of HTTP.

### Background: Previous 429 Rate Limit Issue

In #22242, we encountered 429 rate limit errors when HyperLiquid SDK
v0.25.9 defaulted ALL operations (including write operations like
orders) to WebSocket transport. The solution was to separate transports:
- HTTP for ExchangeClient/InfoClient (request/response)
- WebSocket only for SubscriptionClient (real-time subscriptions)

### Why WebSocket for InfoClient is Now Safe

1. **Reduced API calls**: #23747 reduced init calls from 19 to 15
through caching
2. **Read-only operations**: InfoClient only performs read operations
(market data, user data) - not rate-limited like write operations
3. **ExchangeClient stays HTTP**: Write operations (orders,
cancellations) remain on HTTP to avoid exhausting WebSocket rate limits
4. **Fallback available**: HTTP InfoClient available per-call via
`getInfoClient({ useHttp: true })`

**Problem:**
- Previous optimization (#23747) reduced API calls from 19 to 15
- However, each InfoClient call still created a separate HTTP connection
- 15 HTTP requests = 15 TLS handshakes and connection overhead

**Solution:**
- Use WebSocket transport for InfoClient reads (same transport already
used for SubscriptionClient)
- All 15+ InfoClient API calls now multiplex over a single WebSocket
connection
- Keep HTTP InfoClient as fallback for specific calls if needed
- ExchangeClient (orders, cancellations) remains on HTTP

**Result:** Same number of API calls, but significantly reduced network
overhead (1 connection instead of 15+)

### Architecture Change

| Client | Before | After |
|--------|--------|-------|
| ExchangeClient | HTTP | HTTP (unchanged - required for signing) |
| InfoClient | HTTP | **WebSocket** (default) |
| InfoClient (fallback) | N/A | HTTP (new - per-call override) |
| SubscriptionClient | WebSocket | WebSocket (unchanged) |

### Transport Selection

```typescript
// Default (WebSocket - multiplexed):
const infoClient = this.clientService.getInfoClient();

// Override for specific call (HTTP fallback):
const infoClient = this.clientService.getInfoClient({ useHttp: true });
```

## **Changelog**

CHANGELOG entry: null

## **Related issues**

Follow-up to: #23747 (HIP-3 connection optimization - reduced API calls
from 19 to 15)
Related: #22242 (429 rate limit fix - established HTTP/WebSocket
transport separation)
- #23607
## **Manual testing steps**

```gherkin
Feature: Perps WebSocket Transport Optimization

  Scenario: Faster initialization with multiplexed WebSocket
    Given user has MetaMask mobile app with Perps feature enabled
    When user navigates to Perps tab
    Then Perps markets should load successfully
    And network inspector should show single WebSocket connection for InfoClient calls
    And HIP-3 markets (stocks like TSLA, NVDA) should appear alongside crypto
```

## **Screenshots/Recordings**

N/A - Performance optimization, no UI changes

### **Before**

N/A

### **After**

N/A

## **Pre-merge author checklist**

- [x] I've followed [MetaMask Contributor
Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile
Coding
Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md).
- [x] I've completed the PR template to the best of my ability
- [x] I've included tests if applicable
- [x] I've documented my code using [JSDoc](https://jsdoc.app/) format
if applicable
- [x] I've applied the right labels on the PR (see [labeling
guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)).
Not required for external contributors.

## **Pre-merge reviewer checklist**

- [ ] I've manually tested the PR (e.g. pull and build branch, run the
app, test code being changed).
- [ ] I confirm that this PR addresses all acceptance criteria described
in the ticket it closes and includes the necessary testing evidence such
as recordings and or screenshots.

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> Switches InfoClient to WebSocket by default with an HTTP fallback,
updating service logic, tests, and docs.
> 
> - **Perps Service (`HyperLiquidClientService`)**:
> - Default `InfoClient` to WebSocket transport; add `infoClientHttp` as
HTTP fallback.
> - New `getInfoClient(options?: { useHttp?: boolean })` to select
transport per-call.
> - Update initialization to create both InfoClients; `isInitialized`
now requires both; disconnect clears both.
>   - Historical candles now fetched via WebSocket `InfoClient`.
> - **Tests** (`HyperLiquidClientService.test.ts`):
> - Adjust mocks to return WS then HTTP `InfoClient`; assert dual
initialization and transport selection.
> - Extend tests for `getInfoClient({ useHttp })`, candle fetch via WS,
and subscription/unsubscribe flows.
> - **Docs**:
> - Add transport architecture and selection details in
`docs/perps/hyperliquid/init-flow.md`.
> - Add new `docs/perps/hyperliquid/rate-limits.md` outlining
REST/WebSocket limits.
> 
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
913ab25. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

…nu items (#23784)

## **Description**

Added ramps analytics data to all FundActionMenu buttons (buy-unified,
buy, sell) to match the deposit button's analytics payload. This ensures
consistent analytics tracking across all ramp action buttons.

Changes:
- Added `ramp_routing`, `is_authenticated`, `preferred_provider`, and
`order_count` to buy-unified, buy, and sell button analytics
- Renamed `depositButtonClickData` to `rampsButtonClickData` to reflect
broader usage
- Updated `ActionConfig` type to support boolean and undefined values in
analytics properties

## **Changelog**

CHANGELOG entry: null

## **Related issues**

Fixes: TRAM-2901,
#23777

## **Manual testing steps**

Feature: FundActionMenu Analytics

  Scenario: user taps buy button
    Given the user is on a screen with the FundActionMenu

    When user taps the buy button
Then analytics event BUY_BUTTON_CLICKED is fired with ramp_routing,
is_authenticated, preferred_provider, and order_count properties

  Scenario: user taps sell button
    Given the user is on a screen with the FundActionMenu

    When user taps the sell button
Then analytics event SELL_BUTTON_CLICKED is fired with ramp_routing,
is_authenticated, preferred_provider, and order_count properties##
**Screenshots/Recordings**

### **Before**

N/A - Analytics change only

### **After**

N/A - Analytics change only

## **Pre-merge author checklist**

- [x] I've followed [MetaMask Contributor
Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile
Coding
Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md).
- [x] I've completed the PR template to the best of my ability
- [x] I've included tests if applicable
- [x] I've documented my code using [JSDoc](https://jsdoc.app/) format
if applicable
- [ ] I've applied the right labels on the PR (see [labeling
guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)).
Not required for external contributors.

## **Pre-merge reviewer checklist**

- [ ] I've manually tested the PR (e.g. pull and build branch, run the
app, test code being changed).
- [ ] I confirm that this PR addresses all acceptance criteria described
in the ticket it closes and includes the necessary testing evidence such
as recordings and or screenshots.

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> Unifies ramp analytics across FundActionMenu actions using shared
button click data and updates types/tests accordingly.
> 
> - **UI / FundActionMenu**:
> - Use `useRampsButtonClickData` and add shared analytics fields
(`ramp_routing`, `is_authenticated`, `preferred_provider`,
`order_count`) to `buy-unified`, `buy`, and `sell` button events; keep
existing `region` and chain ID fields.
> - Rename `depositButtonClickData` → `rampsButtonClickData`; update
memo deps accordingly.
> - **Types**:
> - Broaden `ActionConfig.analyticsProperties` to accept `boolean` and
`undefined`.
> - **Tests**:
> - Update `FundActionMenu.test.tsx` to mock `RampsButtonClickData` and
assert new analytics properties for buy flows; maintain behavior that
custom `onBuy` skips analytics.
> 
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
f194d92. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

<!--
Please submit this PR as a draft initially.
Do not mark it as "Ready for review" until the template has been
completely filled out, and PR status checks have passed at least once.
-->

## **Description**

<!--
Write a short description of the changes included in this pull request,
also include relevant motivation and context. Have in mind the following
questions:
1. What is the reason for the change?
2. What is the improvement/solution?
-->

## **Changelog**

<!--
If this PR is not End-User-Facing and should not show up in the
CHANGELOG, you can choose to either:
1. Write `CHANGELOG entry: null`
2. Label with `no-changelog`

If this PR is End-User-Facing, please write a short User-Facing
description in the past tense like:
`CHANGELOG entry: Added a new tab for users to see their NFTs`
`CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker`

(This helps the Release Engineer do their job more quickly and
accurately)
-->

CHANGELOG entry: null

## **Related issues**

Fixes:

## **Manual testing steps**

```gherkin
Feature: my feature name

  Scenario: user [verb for user action]
    Given [describe expected initial app state]

    When user [verb for user action]
    Then [describe expected outcome]
```

## **Screenshots/Recordings**

<!-- If applicable, add screenshots and/or recordings to visualize the
before and after of your change. -->

### **Before**

<!-- [screenshots/recordings] -->

### **After**

<!-- [screenshots/recordings] -->

## **Pre-merge author checklist**

- [ ] I’ve followed [MetaMask Contributor
Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile
Coding
Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md).
- [ ] I've completed the PR template to the best of my ability
- [ ] I’ve included tests if applicable
- [ ] I’ve documented my code using [JSDoc](https://jsdoc.app/) format
if applicable
- [ ] I’ve applied the right labels on the PR (see [labeling
guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)).
Not required for external contributors.

## **Pre-merge reviewer checklist**

- [ ] I've manually tested the PR (e.g. pull and build branch, run the
app, test code being changed).
- [ ] I confirm that this PR addresses all acceptance criteria described
in the ticket it closes and includes the necessary testing evidence such
as recordings and or screenshots.

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> Adds a fork-detection job and conditionally runs the template/label
check; updates checkout and setup-node to v4.
> 
> - **CI Workflow**
(`.github/workflows/check-template-and-add-labels.yml`):
>   - **Fork gating**:
> - Adds `is-fork-pull-request` job using `gh pr view` to set `IS_FORK`.
> - Updates `check-template-and-add-labels` to `needs` this job and
conditionally run only for issues or non-fork PRs.
>   - **Actions upgrades**:
> - Bumps `actions/checkout` to `v4` and `actions/setup-node` to `v4`.
>   - **Condition updates**:
> - Replaces simple `merge_group` skip with combined `always()` +
event/fork checks.
> 
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
653e287. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

<!--
Please submit this PR as a draft initially.
Do not mark it as "Ready for review" until the template has been
completely filled out, and PR status checks have passed at least once.
-->

## **Description**

Add e2e test for the gas less swap

<!--
Write a short description of the changes included in this pull request,
also include relevant motivation and context. Have in mind the following
questions:
1. What is the reason for the change?
2. What is the improvement/solution?
-->

## **Changelog**

<!--
If this PR is not End-User-Facing and should not show up in the
CHANGELOG, you can choose to either:
1. Write `CHANGELOG entry: null`
2. Label with `no-changelog`

If this PR is End-User-Facing, please write a short User-Facing
description in the past tense like:
`CHANGELOG entry: Added a new tab for users to see their NFTs`
`CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker`

(This helps the Release Engineer do their job more quickly and
accurately)
-->

CHANGELOG entry: null

## **Related issues**

Fixes:
https://consensyssoftware.atlassian.net/browse/MMQA-1178

## **Manual testing steps**

```gherkin
Feature: my feature name

  Scenario: user [verb for user action]
    Given [describe expected initial app state]

    When user [verb for user action]
    Then [describe expected outcome]
```

## **Screenshots/Recordings**

<!-- If applicable, add screenshots and/or recordings to visualize the
before and after of your change. -->

### **Before**

<!-- [screenshots/recordings] -->

### **After**

<!-- [screenshots/recordings] -->

## **Pre-merge author checklist**

- [ ] I’ve followed [MetaMask Contributor
Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile
Coding
Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md).
- [ ] I've completed the PR template to the best of my ability
- [ ] I’ve included tests if applicable
- [ ] I’ve documented my code using [JSDoc](https://jsdoc.app/) format
if applicable
- [ ] I’ve applied the right labels on the PR (see [labeling
guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)).
Not required for external contributors.

## **Pre-merge reviewer checklist**

- [ ] I've manually tested the PR (e.g. pull and build branch, run the
app, test code being changed).
- [ ] I confirm that this PR addresses all acceptance criteria described
in the ticket it closes and includes the necessary testing evidence such
as recordings and or screenshots.


<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> Adds a gasless ETH→MUSD swap e2e test verifying the "Included" network
fee, with mocks and QuoteView/selectors support for Max and Included.
> 
> - **Tests**:
> - Add `e2e/specs/swaps/gasless-swap.spec.ts` to validate gasless
ETH→MUSD swap shows `Included` under network fee and uses `Max` amount.
> - **Mocks/Constants**:
> - Add `GASLESS_SWAP_QUOTES_ETH_MUSD` in
`e2e/specs/swaps/helpers/constants.ts` and wire via API mock.
> - **Page Objects**:
> - Update `e2e/pages/swaps/QuoteView.ts` with `maxLink`,
`includedLabel`, and `tapMax()` helpers.
> - **Selectors**:
>   - Extend `QuoteViewSelectorText` with `MAX` and `INCLUDED`.
> 
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
36da9e1. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->